home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 25 / Cream of the Crop 25.iso / faq / preak.zip / MTEXT.ZIP / NCSATELN.PW < prev   
Text File  |  1993-04-13  |  5KB  |  103 lines
  1. A note from your ftp maintainer.
  2.  
  3. Clark Reynard <clark@metal.psu.edu> sent this in.  I am including it
  4. not because it is particularly informative or sophisticated, but as an
  5. illustration of what seems to be an implementation of truly *bad*
  6. cryptography.
  7.  
  8. I would welcome a followup article by anyone who cares to actually
  9. describe the algorithm in question and right a decrypter that makes a
  10. more educated guess as to the answer.  If you want to start somewhere,
  11. this looks like a good place.
  12.  
  13. Enjoy.
  14.  
  15. Eric
  16. -----------------------------------------------------------------------------
  17. Excerpted from PHRACK 41, file 9, by "Bobby Zero," 
  18. "Shortcomings of AppleShare Networks"
  19.  
  20. NCSA TELNET
  21. ~~~~ ~~~~~~
  22. 5) The NCSA Telnet application allows a user to use his or her Mac as a telnet
  23. client and wander around the Internet.  NCSA Telnet also handles incoming FTP
  24. requests.  While this FTP function is easily disabled, many users keep it on
  25. because they either use it regularly or don't even know it exists.
  26.  
  27. * Anyone with a valid username/password can log in to the Mac via FTP and then
  28. change to the "root" directory and perform the normal FTP functions.. both send
  29. and receive.  This means that *every* file on the Mac can be accessed from
  30. *anywhere* on the Internet.  It should be noted that NCSA Telnet does not log
  31. the "who & where" information, meaning there is no log of who used the machine,
  32. meaning there is no way for an intruder to be "caught."
  33.  
  34. * The file "ftppass" contains the list of users allowed to use FTP on that
  35. Macintosh.  If, by using one of the methods mentioned above, someone is able to
  36. access it, it is easily cracked as it has a rather pathetic encryption scheme:
  37. the data fork contains the user's name, a colon, and then an encrypted
  38. password.  The password is easily decrypted; unless it is the entire 10
  39. characters, the last few characters are in order.  That is, the next ASCII code
  40. is 1 + the previous, etc.  Observe this from my "ftppass" file:
  41.  
  42. sample:ucetcr&'()
  43.  
  44. The first part, "sample," is the user's name.  The colon is the basic UNIX-like
  45. delimiter, the rest is the password.  The "real" part of the password is the
  46. characters "ucetcr" ... the remaining "&'()" are just spaces... how do you
  47. tell?  It's in ASCII order.  Look up "&" on an ASCII chart and "'" will follow,
  48. then "(" then ")" .. you get the idea.
  49.  
  50. This password can be discovered by short program XORing the encrypted
  51. characters with a number between 0 and 255.  The program can either a) dump all
  52. XOR results or b) if the password is not the maximum length, the program can
  53. simply scan for a "space" [ASCII 032 decimal] in the password and print it.
  54. The following "cracking" program is written in BASIC [hey, does anyone use that
  55. any more?] and will allow you to decrypt the passwords.  If you can tell that
  56. the password has spaces at the end, you can go ahead and delete line 110.
  57. Otherwise, leave that line in and use your brain [remember your brain?] to
  58. determine if the encrypted goop is a "real" word or just goop.
  59.  
  60. 5 REM "ftppass" brute-force hacker
  61. 10 INPUT "Encrypted password:";I$
  62. 20 FOR X=1 TO 255
  63. 30 FOR Y=1 TO LEN(I$)
  64. 40 Y$=MID$(I$,Y,1)
  65. 50 YA=ASC(Y$)
  66. 60 N=X XOR YA
  67. 70 IF N=32 THEN F=1
  68. 80 N$=N$+CHR$(N)
  69. 90 NEXT Y
  70. 100 IF F THEN ?"Possible password:"N$
  71. 110 ?I$" 'encrypts' to "N$: REM U can delete this line if len<10
  72. 120 N$="":F=0
  73. 130 NEXT X
  74. 140 ?"Finished."
  75.  
  76. Sample run:  [with line 110 deleted]
  77.  
  78. Encrypted password:ucetcr&'()        [gotta type the whole thing]
  79. Possible password:secret !./            [boy, that was tough!]
  80. Possible password:rdbsdu! /.
  81. Possible password:}km|kz./ !            [etc.. just smack ^C at this point.]
  82.  
  83. So the password is "secret" [clever, no?]
  84.  
  85. It should be noted that this program is rather inelegant as I haven't really
  86. reversed the algorithm, just written a brute-force "hacker" for it.  This is
  87. due to laziness on my part.  If I really wanted to do this properly, I would
  88. FTP to the NCSA anonymous site and leech the 700k+ of source and "reverse" it
  89. thataway.  I don't feel like doing that.  I am lazy.  This program works just
  90. dandy for me... [I suspect the encryption program uses the users' name to
  91. encrypt it, but I don't care enough to find out.]
  92.  
  93. I should say that I don't wish to offend the makers of NCSA Telnet or call the
  94. application crap.  It is, indeed, an impressive piece of work; I simply feel
  95. that there are some aspects of it which could use improvement... if not in
  96. terms of security, then at least allowing the user to save selections to disk!
  97.  
  98. BTW- I know that NCSA Telnet is also available for the IBM.  I haven't tested
  99. these with an IBM, but if it's a "true" port, these flaws should exist under
  100. the IBM version as well.
  101.  
  102.  
  103.